26 - SSR, SPAs and PWAs [ID:9498]
50 von 382 angezeigt

Ja, danke schön. Schön, dass Sie hier sind. Ich muss gleich vorweg sagen, ich muss den

Talk auf Englisch machen, weil die Folien sind Englisch und alle meine Notizen sind

Englisch. Wenn ich das auf Deutsch versuche, dann werde ich so, dann wird das so konfus,

dass es für niemanden hier was bringt, wahrscheinlich. Deswegen Englisch. So, Titel

of the talk is SSR, SPAs and PWAs. The subtitle is The Return of Progressive Enhancement,

which is mostly a term of maybe like five to ten years ago, so it was not as important

in the last few years as it was before. My name is Marc Cortevitte. We are all from

of simple apps. We work for international clients, build web apps, both server side and client

side. I'm not going to repeat all that. So, back to the topic. SSR, SPAs, PWAs. So, basically,

the idea of the talk is to look at how those work and how those can work together, which

will also bring us back to the subtitle later on. First of all, though, I want to look at

what these acronyms even mean, because that's obviously the foundation for discussing how

they could work together. And for doing so, we look at an example app. So, we are assuming

an application here that gives access to air quality data, which is obviously an important

topic with upcoming driving bans across Europe. So, let's assume we want to help fix that

air quality situation, raise awareness a bit and give people easy access to air quality

data. So, you might imagine that the start screen for web app that does that might look

something like this. Like you have a search field where you can search for a location

by name. Let's say you search for Erlangen or so. Or most of the time probably you would

be interested in air quality data for your current location, like around you, because

that's the air you're breathing, obviously. So, anyway, though, any way you start the

search, you get to a result list there, which might look something like this. It's just

a list of results with links to kind of the actual detail pages for those locations.

And then the detail page might look like this. It might say, excellent air, very bad air,

and here's why. Because PM so and so is really high or CO2 is low or whatever. So, let's

look at different ways of building an application like that. And first of all, we look at classic

website, the classic SSR server-side rendered website, where the application is, like I

said, fully rendered on the server side. Or maybe it's pre-rendered, maybe it's just

a static HTML file. And that HTML that the server has is then sent to the client. It's

a complete document that the client, the browser receives, and that's maybe enhanced in the

browser with some JavaScript or so. A concrete example is like this. Here we have the server

on the right, and the browser makes the request for that initial document, like get slash,

get the root page of the document. It gets the document from the server. Then you would

enter search term. You would start the search that results in another request to the server

again, which again responds with a pre-rendered or with a server-side rendered document. And

then you select one of these locations, results in another request, and you get another server-side

rendered document for the results of, for the air quality results for that particular

location. The characteristics of the approach are obviously the document is visually complete

as it is received from the server. The document contains everything that's needed, like all

the information and all the logic and all the styling sort of is included in that document,

leaving alone that the styles are probably in an external style sheet, but all of the

application of the classes and so on. That's all in that server-side rendered document.

And also the document immediately function. You can immediately, as you receive the document,

as it gets rendered by the browser, you can immediately fill in the search form and submit

it back to the server-side. And of course, all pages are independent of each other. So

every time you switch to a different page or you submit the form or whatever, you have

like a full request-response cycle and reload the complete page. Just classic way of how

the web works. The first iteration step on that classic approach sort of was single-page

apps, where you essentially ship an empty document to the browser that just has some script tags,

the browser loads the script, boots up the application, and then everything runs in

Teil einer Videoserie :

Presenters

Marco Otte-Witte Marco Otte-Witte

Zugänglich über

Offener Zugang

Dauer

00:45:58 Min

Aufnahmedatum

2018-09-13

Hochgeladen am

2018-09-13 17:27:23

Sprache

en-US

Outline:

SSR recap – what is it, how does it work?

* send pre-rendered vs. empty document
* improving perceived performance
* Giving non-JS clients something they can work with (e.g. Twitter Cards etc.)

Typical problems

* jQuery obviously not available
* => problems with SSR mostly caused by bad patterns (e.g. jQuery)
* Relying on `localStorage`/`sessionStorage` => move to cookie

Disabling interaction on the pre-rendered document

* Simple case is to disable complete document => result often not great
* Better:
* selectively disable elements that require app to run
* Render them in a loading state (signals the user “this is still setting up”)
* Some elements are functional without a running app already
* Some things can be moved to CSS

Advanced patterns

* Lazy load in the client, bundle everything in SSR as bundle size does not matter much there (e.g. translations)
* Push data in the sandbox (e.g. translations, model data etc.)
* Render differently in SSR/client (e.g. inline SVG in SSR, use image tag in browser)
* Never require SSR to work (fallback to serving non-SSR on SSR errors)

how does this relate to PWAs

* Works well together:
* App frame is fine but app frame + SSR is better
* This can be combined – render app frame first, then put in SSR once available, while app still loads

Whether SSR worth it depends on case though

Tags

Webdesign WKE WKE2018 Webentw A11Y webkongress cms bytes resource around page response conceptual difference shared javascript breethe browser work spa ssr cache central server network
Einbetten
Wordpress FAU Plugin
iFrame
Teilen